View AN2540_8146532.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

april 2013 rev 2 1/25 AN2540 application note eeprom emulation in str91xfxx devices introduction replacing external eeprom with emulated eepr om from the embedd ed-flash memory of the microcontroller is a complex development. this application note is aimed at readers that are already familiar with the techniques used to secure th e content of evolutive information in the external eeprom of embedded applications.this app lication note explains the differences between external /internal eeproms and embedded -flash memory. it also gives advice on how to replace extern al eeprom with emulated-eeprom using the on-chip flash memory of str91xfxx devices. this document also focuses on some embedded aspects in emulated-eeprom data storage, that are assumed to be known by the reader. overview electrically erasable and programmable read-only memory (eeprom) is a key component in many embedded applications requiring non-volatile storage of data that are updated at a byte, half-word or word granularity during run time. on the other hand, the microcontrollers used in those systems are more and more based on embedded-flash memory. to elim inate components, save silic on area and reduce system cost, the str91xfxx flash memory could eventually replace the external eeprom for simultaneous code and data storage. however unlike flash memory, external eeprom does not require a block erase operation to free up space before data can be rewritten. a special software management is required to store data into flash memory. obviously the emulatio n software scheme d epends on many factors including the eeprom reliability, flash memory ar chitecture and product requ irements. two approaches to implementation are described in detail in this application note using the on-chip flash memory of the str91xfxx microcontrollers. www.st.com
contents AN2540 - application note 2/25 contents 1 embedded flash memory vs. eeprom: main differences . . . . . . . . . . 5 1.1 difference in write access time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 difference in writing method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 difference in erase time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 appropriate solution for emulated e eprom in the str 91xfxx . . . . . . 7 2.1 str91xfxx on-chip flash memory features . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 str91xfxx flash memory library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 implementing the eeprom emulation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 1st method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 application example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 eeprom software description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 2nd method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.1 application example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.2 eeprom software description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4 program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4 embedded application aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1 data granularity management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.1 programming on a word-by-word basis . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2 programming on a byte-by-byte basis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 wear-leveling: flash endurance improvement . . . . . . . . . . . . . . . . . . . . . 19 4.2.1 application example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 sector header recovery in case of power loss . . . . . . . . . . . . . . . . . . . . . 20 4.4 emulated eeprom parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.1 program/erase parameter cycling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.2 program timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
AN2540 - application note list of tables 3/25 list of tables table 1. differences between embedded flash memory and eeprom . . . . . . . . . . . . . . . . . . . . . . 5 table 2. eepromformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 table 3. findvalidsector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 table 4. readvariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 table 5. writevariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 table 6. writeverifyvariablefull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 table 7. eepromsectortransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 table 8. status combinations and actions to be taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 table 9. write time related to the current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 table 10. document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
list of figures AN2540 - application note 4/25 list of figures figure 1. header field status switching between sector0 and 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 figure 2. sector swap scheme: sector1 erased . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 figure 3. sector swap scheme: sector0 erased . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 figure 4. 1st method: writevariable flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 figure 5. data storage procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 figure 6. data update flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 figure 7. 2nd method: writevariable flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 figure 8. writeonebyte function description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 figure 9. sector swap scheme with four sectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
AN2540 - applicati on note embedded flash memory vs. eeprom: main differences 5/25 1 embedded flash memory vs. eeprom: main differences before describing the pro posed concept for eeprom emul ation, it is important to remember the main differences between the embedded flash memory of a microcontroller and serial external eeproms. t hese differences are the same for any microcontroller (that is they are not specific to str91xfxx products). they are summarized in ta b l e 1 . 1.1 difference in write access time as the flash memory has a shorter write access time, critical parameters can be stored faster into the emulated eepr om than into an external se rial eeprom. the use of the flash memory therefore improves the system robustness. 1.2 difference in writing method one of the major differences between external and emulated eeprom for embedded applications is th e writing method. standalone external eeprom: once started by the cpu, the writing of a word cannot be interrupted by a cpu reset. only a powe r supply failure can interrupt the writing process, so properly sizing the decoupling ca pacitors can secure the write process to a standalone eeprom. emulated eeprom from an embedded flash memory: once started by the cpu, the writing can be interrupted by a power failure and by a cpu reset. this difference should be analyzed by system designers to understand the possible impact(s) in their applications, and to determine a proper method to handle them. table 1. differences between embedded flash memory and eeprom feature external eeprom emulated eeprom using on-chip flash memory write time a few ms ? random byte: 5 to 10 ms ? page: equivalent to a hundred s per word (5 to 10 ms per page) a few s (e.g.: 20 s per 16-bit word) erase time n/a seconds (e.g.: 1.5 s) write method once started, is not cpu-dependent, needs only proper supply. once started, is cpu-dependent: a cpu reset will stop the write process even if the supply stays within specifications. read access serial: a hundred s random word: 92 s page: 22.5 s/byte parallel: a hundred ns very few cpu cycles per 16-bit word.
embedded flash memory vs. eeprom: main differences AN2540 - application note 6/25 1.3 difference in erase time the difference in eras e time is the other major differen ce between standalone eeprom and emulated eeprom with embedded flash memory. unlike flash memory, eeprom does not require a block erase operation to free up space before writing. moreover, as the erase process of a block in the flash memory takes a few seconds, power shut-down and other spurious events that may interrupt the erase process (e.g.: reset) should be considered when designing the flash memory management software. this means that to design a robust flash memory management software it is necessary to have a good understanding of the flash memory erase process.
AN2540 - application note appropriate solution for emulated eeprom in the str91xfxx 7/25 2 appropriate solution for emulated eeprom in the str91xfxx the str91xfxx microcontrollers support the hardware and software architecture necessary to emulate eeprom memory using the on-chip flash memory. 2.1 str91xfxx on-chip flash memory features the str91x internal flash memo ry consists of two banks: main flash memory (bank 0) and secondary flash memory (bank 1). the main flash memory is up to 512 kbytes in size and includes up to eight 64-kbyte sectors. the secondary flash memory is 32 kbytes in size and consists of four 8-kbyte se ctors, it can be useful for the wear-leveling feature (refer to section 4.2 ). one of the str9 embedded flash memory features is read-while-write (rww) dual bank operations. this means that the main flash memory (bank0) can be used for code storage and the smaller secondary flas h memory, for data storage (eeprom emulation). the flash memory can be erased on a sector or bank basis, and programmed on a 16- bit half-word basis. each bank can be programmed and erased over 100 000 cycles. 20-year data retention. each sector can be individually protect ed and unprotected against program and erase operations. as the flash memory has a shorter write access time, critical parameters can be stored faster in the em ulated eeprom than in an external serial eeprom. interrupt servicing during program/erase is possible. cpu program does not need to be copied into ram during program/erase: ram less used to perform eeprom emulation. program/erase suspend and resume commands supported. that is, flash memory sector erase may be suspended while data is read from other sectors in the same flash memory bank, and then resumed after reading. 2.2 str91xfxx flash memory library the flash memory programming library is a set of optimized c routines. it contains all that is needed to program the flash memory embedded in str9 devices. the flash memory library contains the following source files: 91x_fmi.c, that contains the function codes 91x_fmi.h, that contains the function prototypes to use the functions provided by the flash memory library, these two files must be added to the project. with the str9 software (sw) library (fmi driver) it is easy to implement the eeprom emulation software.
implementing the eeprom emulation AN2540 - application note 8/25 3 implementing the eeprom emulation 3.1 principle this emulation is performed in various ways by considering the flash memory limitations and the product requirements. two approaches are described below in detail. both require a minimum of two flash memory sectors of identical size, that are allocated to non-volatile data. one that is initially erased and can be programmed byte by byte, and the other that is ready to take over when the first sector needs to be garbage-collected. since the str91xfxx on-chip flash memory can be programmed on a 16-bit half-word basis, the data granularity in this implementation is 16 bits. a header field that occupies the first 16-bit half word of each sector indicates the sector status. each sector has four possible states: erased : the sector is empty. receive_data : the sector is receiving data from the full sector. valid_sector : the sector contains valid data and its state will not change until valid data are completely transferred to the erased sector. transfer_complete: transfer of data to the other sector is finished and this sector is no longer in use. the system can then erase it and prepare it for future data. figure 1. shows how to switch from one state to another for both sectors. figure 1. header field status switching between sector0 and 1 valid0 erased1 valid0 receive1 transfer_ complete0 valid1 erased0 valid1 receive0 valid1 transfer_ complete1 valid0 sector0 full transfer data from sector0 to sector1 complete erase0 sector1 full write data in sector0 copy data from sector0 erase1 to sector1 copy data from sector1 to sector0 write data in sector1 transfer data from sector1 to sector0 complete states related to sector1 states related to sector0 ai14085
AN2540 - application note imple menting the eeprom emulation 9/25 3.2 1 st method parameter records stor ed in eeprom vary in size and update frequency. users using this method would usually know the update frequency in advance. in this method, sector0 and sector1 in bank1 are used. these flash memory sectors are write-accessed in order to store several non-volatile variables. for this purpose, they have to be divided identically into several parts, one per variable. the size of the memory space allocated to each variable depends on the variable update frequency. the first 16-bit value of each variable is stored at the base address of the memory space allocated to the variable. when the variable is updated, the new value is stored at the next available address: base address + 2, base address + 4 and so on until no room remains in the allocated memory space. the 1 st method emulation driver meets the following requirements: at least two boot flash memory sectors have to be used, more if possible for wear leveling (refer to section 4.2 ) minimum use of sram simple and easily updatable code model user api consisting of eepromformat, findvalidsector, writevariable, readvariable. clean-up and internal data management transparent to the user code in main flash memory, data storage in secondary flash memory 3.2.1 application example let us assume that in sector0, three vari ables: a, b and c, will be stored a nd updated. the first variable a value is stored at t 0 and variable a(t) is updated every t a . the second variable b value is stored at t 1 and variable b(t) is updated every t b . the third variable c value is stored at t 2 and variable c(t) is updated every t c . in a typical application, the majority of non-volatile data are seldom updated, only a few data are updated more frequently. let us consider t c < t a < t b . this means that c is updated more often than a and b, and that a is updated more often than b. so more memory space should be allocated to c than to a and b, and a should have more space than b (refer to figure 2 ).
implementing the eeprom emulation AN2540 - application note 10/25 figure 2. sector swap scheme: sector1 erased in this application, sector 0 is divided up as follows: 0x0000 0002 - 0x0000 04ff memory space is allocated to variable a 0x0000 0500 - 0x0000 0510 memory space is allocated to variable b 0x0000 0511 - 0x0000 1fff memory space is allocated to variable c in sector0, variables are stored until there the memory space left is not large enough to be allocated to another variable (case of variable a in the following example). example: let us assuming that variable a is to be updated at time t0 + (n+1) ta to a(t0 + (n+1) ta). addresses from 0x0000 0002 to 0x0000 04ff are all full, the next value is then stored in the base address of the space allocated to variable a in sector1. the latest stored values of all other variables (b and c) are transferred from their current location in sector0 to the base address of their allocated space in sector1. after the transfer of all variables is complete, sector0 is erased. variables are then stored and updated in sector1 in the same way as described for sector0. when there is not enough memory space left for one of these variables in sector1, the variables are transferred back to sector0 (now empty) as described above and so on. this process is illustrated in figure 3 . a(t) values b(t) values c(t) values 0x0000 0000 0x0000 1fff a(t 0 ) b(t 0 ) c(t 0 ) sector0 sector1 header a(t) values b(t) values c(t) values 0x0000 2000 0x0000 3fff sector1 erased update update update sector swap (erase one when using the other) a(t 0 + t a ) a(t 0 + n t a ) b(t 0 + m t b ) c(t 0 + p t c ) sector0 header a(t 0 ) b(t 0 ) c(t 0 ) a(t 0 + t a ) a(t 0 + n t a ) b(t 0 + m t b ) c(t 0 + p t c ) ai14086
AN2540 - application note imple menting the eeprom emulation 11/25 figure 3. sector swap scheme: sector0 erased 3.2.2 eeprom software description this section describes the driver implemented for eeprom emulation using the str91xfxx flash library provided by stmicroelectronics. a demonstration program is also supplied to demonstrate and test the eeprom emulation driver using the three variables a, b and c already defined. the project contains three source files in addition to the fmi library source files: eeprom.c: containing c code for the following routines: eepromformat() writevariable() readvariable() findvalidsector() writeverifyvariablefull() eepromsectortransfer() eeprom.h: containing the routines? prototypes and some declarations. main.c: this application program is an ex ample using the routines described in eeprom.c. a(t) values b(t) values c(t) values 0x0000 0000 0x0000 1fff a(t 0 ) b(t 0 ) c(t 0 ) sector0 erased sector1 header a(t) values b(t) values c(t) values 0x0000 2000 0x0000 3fff sector1 update update update sector swap (erase one when using the other) a(t 0 + t a ) a(t 0 + n t a ) b(t 0 + m t b ) c(t 0 + p t c ) sector0 header 0 a(t + (n + 1) t a ) b(t 0 + m t b ) 0 c(t + p t c ) ai14087
implementing the eeprom emulation AN2540 - application note 12/25 3.2.2.1 user api definition table 2. eepromformat function name eepromformat function prototype u8 eepromformat(void); behavior description this function erases sector 0 and sector1 and writes a valid_sector header to sector0. input parameter none return parameter status of the operation. called functions fmi_erasesector,fmi_waitforlastoperation,fmi_writehalfword table 3. findvalidsector function name findvalidsector function prototype u8 findvalidsector(u8 operation); behavior description this function reads both sector?s headers and returns the sector number which contains valid data. input parameter a byte indicating that we are looking for a valid sector for write or read operation(read_from_valid_sector or write_in_valid_sector return parameter sector number. called functions fmi_readword. table 4. readvariable function name readvariable function prototype u16 readvariable(u8 index, u32 *t); behavior description this function reads variable data. only last update is read. the function enters a loop in which it reads the variable entries until the last one is found. finally, the data is returned. input parameter ? index: variable identifier ? t: variable array return parameter returns 16-bit read data on success or error code on failure. called functions findvalidsector. table 5. writevariable function name writevariable function prototype u8 writevariable(u8 index, u32 *t, u16 data); behavior description this function is called by the user application to update a variable input parameter ? index: variable identifier ? t: variable array ? data: 16-bit data to be written return parameter returns 1 on success or error code on failure called functions writeverifyvariablefull, eepromsectortransfer.
AN2540 - application note imple menting the eeprom emulation 13/25 the procedure of updati ng a variable entry in the eeprom is shown in figure 4 . figure 4. 1 st method: writevariable flowchart if the data to be written is equal to 0xffff, it is necessary to find the last data equal to 0xffff and to write 0x0000 into the next loca tion to indicate that 0xffff represents data and not a blank location. if the data to be written is different from 0xffff, it is then written to the last location that contains 0xffffh (the following location should not contain 0x0000). this function returns 0 on success, variable_full if there is not enough memory space for a variable update, or a flash error code indicating an operation failure (erase or program). table 6. writeverifyvariablefull function name writeverifyvariablefull function prototype u16 writeverifyvariablefull(u8 index, u32 *t, u16data); behavior description if a write operation takes place, the write process must either update a variable, or create the first instance of a variable. input parameter ? variable index, in the demonstration example provided: (0 for a, 1 for b or 2 for c). ? t: variable array ? 16-bit data to be written return parameter returns 1 on success or 0x80 if variable is full or flash error code called functions findvalidsector,f mi_readword,fmi_writehalfword add element request full current record add new element at the 1st empty element place in the current record of active sector erase previous active sector end end change the active sector find valid sector yes no findvalidsector() writeverifyvariablefull() copy each latest element of each available record by reading from bottom taking into account the new updated element. eepromsectortransfer() readvariable() function call ai14088
implementing the eeprom emulation AN2540 - application note 14/25 at the beginning, the function determines the active sector which is the sector to be transferred from. the new sector header field is defined and written (new sector status is receive_data given that it is in the process of receiving data). when the data transfer is complete, the new sector header is marked valid_sector and the old one transfer_complete. at the end, the old sector is erased. 3.2.2.2 key features of the 1 st method ? user-configured emulated eeprom size. ? the number of flash program/erase cycles used can be minimized by permanently allocating a large memory space to the most frequently updated non-volatile data variables. ? readvariable and writevariable functions to access variables. ? the whole available memory space is used to store data: no need for virtual addresses. ? fast read access to any variable since this simply implies going to the corresponding allocated memory space. ? interrupt servicing during program/erase is possible. table 7. eepromsectortransfer function name eepromsectortransfer function prototype u8 eepromsectortransfer(u8 index, u32 *t, u16 data); behavior description it transfers the most recent data (last variable updates) plus the new data from a full sector to an empty one. input parameter ? index: variable identifier (0, 1, 2...) ? t: variable array ? data: 16-bit data to be written return parameter returns 1 on success or error code on failure called functions findvalidsector,fmi_writehalfword, writeverifyvariablefull, readvariable, fmi_erasesector.
AN2540 - application note imple menting the eeprom emulation 15/25 3.3 2 nd method generally when using this method, the user does not known in advance the update frequency of the variables. to emulate the eeprom, two sector data structures are used. each data element is defined by a virtual address and its value to be stored into flash memory locations for subsequent retrieval or update. when data is modified, the data associated with the earlier virtual address is stored into a new flash memory location. during data retrieval, the modified data, in the latest flash memory location is returned. figure 5. data storage procedure 3.3.1 application example this example shows three eeprom variab les with the following virtual addresses: var1: aaaah var2: 5555h var3: ddaah the data update flow is shown in figure 6. eeprom virtual @ (16 bits) sector1 sec tor0 32 bits 2048 elements (8 kb) eeprom data (16 bits) eeprom element = 32-bit word ai14089
implementing the eeprom emulation AN2540 - application note 16/25 figure 6. data update flow 3.3.2 eeprom software description the user api function naming is the same as in the 1 st method routines, the main differences are shown in the writevariable flowchart given in figure 7. 12 32 dd aa 12 45 dd aa bc bc aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 34 34 55 55 12 32 dd aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 12 32 dd aa 12 45 dd aa bc bc aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff sector0 sector1 active sector = sector0 ff ff ff ff ff ff ff ff 32 32 dd aa 22 45 dd aa bd bd aa aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 54 54 55 55 12 32 dd aa add var3 =1232h add var3 =1245h add var1 =bcbch add var2 =6464h erase sector0 add var2 =3434h the most recent data (last variable updates) are transferred from sector0(as full sector) to sector1 (as empty sector). sector0 sector1 active sector = sector0 sector0 sector1 active sector = sector0 12 32 dd aa 12 45 dd aa ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff sector0 sector1 active sector = sector0 sector0 sector1 active sector = sector0 sector0 sector1 active sector = sector0 sector0 sector1 active sector = sector0 32 32 dd aa 22 45 dd aa bd bd aa aa 64 64 55 55 22 45 dd aa bd bd aa aa ff ff ff ff ff ff 54 54 55 55 12 32 dd aa sector0 sector1 active sector = sector0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ai14090
AN2540 - application note imple menting the eeprom emulation 17/25 figure 7. 2 nd method: writevariable flowchart 3.3.2.1 key features of the 2 nd method ? user-configured emulated eeprom size. ? increased flash memory endurance: sector erased only once it is full. ? non-volatile data variables can be updated infrequently ? no need to perform a write operation if the updated value is the same. ? interrupt servicing during program/erase is possible. 3.4 program execution independently of the implementation scheme, the str91xfxx internal flash memory offers the ability to update a bank while code is execut ed from the other bank . therefore, there is no need to transfer flash memory operations (program/erase) to ram. however when the cpu frequency is higher then 25 mhz it is recommended to copy some routines into ram this means that before erasing and programming, a few software routines have to be copied from the flash memory into the on-chip ram. should be copied at least the routines used for the erase and program operations, and the routines that run while the erase or program operation is ongoing. add element request full current active sector add new element at the 1st empty element place in the current active sector erase previous active sector end end change the active sector find valid sector yes no findvalidsector() writeverifyvariablefull() copy all current elements by reading the active sector from the bottom, taking into account the new updated element. eepromsectortransfer() readvariable() function call ai14091 check value same different end
embedded application aspects AN2540 - application note 18/25 4 embedded application aspects this section gives some advice on how to overcome software limitations in embedded applications and to fulfill the nee ds of differen t applications. 4.1 data granularity management the emulated eeprom can be used in embedded applications where non-volatile storage of data updated with a byte, half-word or word granularity is required. it generally depends on the user requirements and flash architecture, such as stored data length, write access, etc. the str91xfxx on-chip flash memory allows 16-bit, half-word programming. data can however be programmed by bytes or words by using some software techniques. 4.1.1 programming on a word-by-word basis to write 32 bits of data "fmi_data" to the desired flash memory address "fmi_address" in bank1 for example, the process is the following: write the lsb part of the data (the first two bytes) to the desired flash memory address. write the msb part of the data (the last two bytes) to the flash memory address incremented twice. 4.1.2 programming on a byte-by-byte basis writing by bytes offers the us er the possibility to cover th e entire memory space and, therefore, to store more data. the performance may however be reduced. a simple example can be useful to understand how to implement such a feature. let us assume for example that we want to write one byte of data "0xdd" into bank1 at the fmi_address. this can be achieved as follows: if fmi_address is even, then 0xffdd is written. if fmi_address is odd, 0xddff is written. the generic scheme is shown in figure 8. u16 lsb=fmi_data; u16 msb= fmi_data >>16; fmi_writehalfword ( fmi_address, lsb); fmi_waitforlastoperation(fmi_bank_1); fmi_writehalfword ( fmi_address+2, msb);fmi_waitforlastoperation(fmi_bank_1);
AN2540 - application note embedded application aspects 19/25 figure 8. writeonebyte function description the above function is used to write the "fmi_data" data byte to the "fmi_address" address. 4.2 wear-leveling: flash endurance improvement in the str91xfxx on-chip flash memory, each sector can be programmed or erased reliably over 100 000 times. for write-intensive applications that use more than two sectors (3 or 4) for the emulated eeprom, it is recommended to implement a wear-leveling algorithm to monitor and distribute the number of write cycles among the sectors. when no wear-leveling algorithm is used, the sectors are not used at the same rate. sectors with long-lived data do not endure as many writ e cycles as sectors that contain frequently updated data. the wear-leveling algorithm ensures that equal use is made of all the available write cycles for each sector. 4.2.1 application example in this example, in order to enhance the emulated eeprom capacity, four sectors will be used. to implement the wear-leveling algorithm with the 2 nd method scheme, the procedure is the following: when sector n is full, switch to sector n+1. sector n is then garbage-collected. let us consider the four sectors of the example: when sector3 is full, the device goes back to sector0, then sector 3 is garbage-collected and so on (refer to figure 9. ). void writevariable(u32 fmi_address,u8 fmi_data) { if (fmi_address &1) { fmi_writehalfword(fmi_address,((fmi_data << 8) | 0xff)); fmi_waitforlastoperation(fmi_bank_1); } else { fmi_writehalfword(fmi_address,(0xff00 |fmi_data)); fmi_waitforlastoperation(fmi_bank_1); } }
embedded application aspects AN2540 - application note 20/25 figure 9. sector swap scheme with four sectors the previous algorithm can be implemented in the findvalidsector(...) function. 4.3 sector header recove ry in case of power loss data or sector header corruption is possible in case of a power loss during a variable update, a sector erase or a transfer. to detect this corruption and recover it, an in itialization routine should be called immediately after power-up. after power loss, this routine is used to check the sector header status and to perform repair if necessary. there are 16 possible status combinations, half of which are invalid. the following table shows the actions that should be taken based on the sector states upon power-up. 12 32 dd aa ff ff ff ff ff ff ff ff ff ff active sector ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff erased erased erased sector0 sector1 sector2 sector3 ai14092
AN2540 - application note embedded application aspects 21/25 4.4 emulated eeprom parameters 4.4.1 program/erase parameter cycling one program/erase cycle consists of one or more write accesses and one sector erase operation. when the eeprom techno logy is used, each byte can be programmed and erased a finite number of times, typically in the range of 10 000 to 100 000. however, when the flash memory is used, t he minimum erase size is the sector and the number of program/erase cycles applied to a sector is the number of erase cycles. the str91xfxx electrical characteristics guarantee 100 000 program/erase cycles per sector. generally the maximum life of the eeprom is ther eby limited to the update rate of the most frequently written parameter. in the 1 st scheme application example, two sectors of 8 kbytes are used and programming is done on a 16-bit half-word basis. if we consider that the memory space allocated to variable c is always filled before the memory spaces allocated to variables a and b, the expected number of erase cycles depends on variable c. as 6896 bytes are allocated to c, the variable can be updated 3448 times before it is switched to the other sector and the first sector is erased. two sectors are used that can be erased 100 000 times so the total number of cycles we can expect for c is: 3448 2 100 000 = 689 600 000 cycles. table 8. status combinations and actions to be taken sector 1 sector 0 erased receive_data valid_data transfer complete erased invalid state so erase both sectors and format sector 0 invalid state so erase both sectors and format sector 0 use sector 0 as valid sector and erase sector 1 invalid state: erase both sectors and format sector 0 receive_data invalid state: erase both sectors and format sector 0 invalid state: erase both sectors and format sector 0 use sector 0 as valid sector & erase sector1 & transfer data from sector0 to sector1 use sector 1 as valid sector & erase sector 0 valid_data use sector 1 as valid sector and erase sector 0 use sector 1 as valid sector & erase sector 0 & transfer data from sector1 to sector0 invalid state: erase both sectors and format sector0 use sector 1 as valid sector and erase sector 0 transfer complete invalid state: erase both sectors and format sector 0 use sector 0 as valid sector and erase sector 1 use sector 0 as valid sector and erase sector 1 invalid state: erase both sectors and format sector 0
embedded application aspects AN2540 - application note 22/25 4.4.2 program timing the following table gives an idea about the emulated eeprom write time related to the current implementation. it is clear that updating a variable with the 1 st method scheme takes less time than with the 2 nd method scheme since only the corresponding allocated memory space is accessed in the first case and not the whole sector. table 9. write time related to the current implementation implemented scheme parameter write time (typical) write time (max) (1) 1. this is the time taken to update a variable that make s a call to the eepromsector transfer(..) function. it is nearly equal to the sector erase time. 1 st method scheme 20 s 300 ms 2 nd method scheme 30 s 300 ms
AN2540 - application note conclusion 23/25 5 conclusion the external eeprom can be replaced by an emulated eeprom usin g the on-chip flash memory of str91xfxx devices. with the shorter flash memory write access time, critical parameters are stored faster into the emulated eeprom than into an external serial eeprom. however, because the fl ash memory needs to be eras ed before being written, some form of software management is requ ired to store data into the emulated eeprom. two methods are used to implement an emulated eeprom: both require a minimum of two flash memory sectors of identical size, allocate d to non-volatile data. one that is initially erased and can be programmed byte by byte, and the other that is ready to take over when the first sector needs to be garbage-collected. the emulated eeprom can be us ed in embedded app lications where n on-volatile data storage is required, with a byte, half-word or word granularity. the str91xfxx on-chip flash memory allows 16-bit, half-word programming. data can however be programmed by bytes or words by using some software techniques. for write-intensive applications that use more than two sectors (3 or 4) for the emulated eeprom, it is recomme nded to implement a wear-leve ling algorithm to monitor and distribute the number of write cycles among the sectors.
revision history AN2540 - application note 24/25 6 revision history table 10. document revision history date revision changes 01-jun-2007 1 initial release. 05-apr-2013 2 changed part number to str91xfxx. updated disclaimer.
AN2540 - application note 25/25 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a parti cular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. st products are not authorized for use in weapons. nor are st products designed or authorized for use in: (a) safety critical applications such as life supporting, active implanted devices or systems with product functional safety requirements; (b) aeronautic applications; (c) automotive applications or environments, and/or (d) aerospace applications or environments. where st products are not designed for such use, the purchaser shall use products at purchaser?s sole risk, even if st has been informed in writing of such usage, unless a product is expressly designated by st as being intended for ?automotive, automotive safety or medical? industry domains according to st product design specifications. products formally escc, qml or jan qualified are deemed suitable for use in aerospace by the corresponding governmental agency. resale of st products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or registered trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2013 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - philippines - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of AN2540

	To Download AN2540 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .